In the event of a system failure, SQL Server must preserve any information necessary to return to operations with least disruption to mission processes.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-67377	SQL4-00-021210	SV-81867r1_rule		Medium

Description
Discretionary Access Control (DAC) is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled table permissions. When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. The policy is bounded by the information system boundary. Once the information is passed outside of the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.

Description

Discretionary Access Control (DAC) is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled table permissions. When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. The policy is bounded by the information system boundary. Once the information is passed outside of the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.

STIG	Date
MS SQL Server 2014 Database Security Technical Implementation Guide	2016-04-20

Details

Check Text ( C-67955r1_chk )
Review the system security plan (SSP) to determine whether the database is static, the recovery model to be used, the backup schedule, and the plan for testing database restoration. If the SSP does not state that the database is static, assume that it is not static. If any of the other information is absent, this is a finding. If the database is not static, but the documented recovery model is Simple, this is a finding. If the database is not static, and the documented recovery model is Bulk Logged, but the justification and authorization for this are not documented, this is a finding. In SQL Server Management Studio, Object Explorer, right-click on the name of the database; select Properties. Select the Options page. Observe the Recovery Model field, near the top of the page. If this does not match the documented recovery model, this is a finding. In Object Explorer, expand >> SQL Server Agent >> Jobs. Review the jobs set up to implement the backup plan. If they are absent, this is a finding. Right-click on each backup job; select View History. If the history indicates a pattern of job failures, this is a finding. Review evidence that database recovery is tested annually or more often, and that the most recent test was successful. If not, this is a finding.

Check Text ( C-67955r1_chk )

Review the system security plan (SSP) to determine whether the database is static, the recovery model to be used, the backup schedule, and the plan for testing database restoration. If the SSP does not state that the database is static, assume that it is not static. If any of the other information is absent, this is a finding.

If the database is not static, but the documented recovery model is Simple, this is a finding.

If the database is not static, and the documented recovery model is Bulk Logged, but the justification and authorization for this are not documented, this is a finding.

In SQL Server Management Studio, Object Explorer, right-click on the name of the database; select Properties. Select the Options page.

Observe the Recovery Model field, near the top of the page. If this does not match the documented recovery model, this is a finding.

In Object Explorer, expand >> SQL Server Agent >> Jobs.

Review the jobs set up to implement the backup plan. If they are absent, this is a finding.

Right-click on each backup job; select View History. If the history indicates a pattern of job failures, this is a finding.

Review evidence that database recovery is tested annually or more often, and that the most recent test was successful. If not, this is a finding.

Fix Text (F-73489r1_fix)
Modify the system security plan, to include whether the database is static, the correct recovery model to be used, the backup schedule, and the plan for testing database restoration. In SQL Server Management Studio, Object Explorer, right-click on the name of the database; select Properties. Select the Options page. Set the Recovery Model field, near the top of the page, to the correct value. In Object Explorer, expand >> SQL Server Agent >> Jobs. Create, modify and delete jobs to implement the backup schedule. (Alternatively, this may done using T-SQL code.) Correct any issues that have been causing backups to fail. Test the restoration of the database at least once a year; correct any issues that cause it to fail. Maintain a record of these tests.

Fix Text (F-73489r1_fix)

Modify the system security plan, to include whether the database is static, the correct recovery model to be used, the backup schedule, and the plan for testing database restoration.

In SQL Server Management Studio, Object Explorer, right-click on the name of the database; select Properties. Select the Options page. Set the Recovery Model field, near the top of the page, to the correct value.

In Object Explorer, expand >> SQL Server Agent >> Jobs. Create, modify and delete jobs to implement the backup schedule. (Alternatively, this may done using T-SQL code.)

Correct any issues that have been causing backups to fail.

Test the restoration of the database at least once a year; correct any issues that cause it to fail. Maintain a record of these tests.